1. Field
The present disclosure generally relates to a method, apparatus, and computer usable code for remotely loading and managing artifacts.
2. General Background
An artifact is data that an application requests for use in running or executing a process. This data may be, for example, an entry from a database, a text file, a table, a class, a dynamically linked library (DLL) file, a value, or a like object. Artifacts are often required to be shared between one or more applications.
Some typical solutions for sharing artifacts include sharing by copy, shared library, database-artifact registry models and passing artifacts with instance data.
A shared by copy approach involves copying the artifact into each application's scope. However, there are many drawbacks to such an approach. One drawback is that version control becomes hard. When the shared artifact needs to be changed, each of the applications which uses the artifact needs to be uninstalled and redeployed. Another drawback with the shared artifact approach is that implementing dynamicity is quite difficult. For example, in the case of a generic administrative application which manages other applications on a server, each time a new application with new artifacts is installed that the administrative application needs to manage, the administrative application must be stopped and even uninstalled. The new artifacts then must be copied to the administrative application. Further, the administrative application has to be redeployed. Finally, there is a lack of proper data isolation with the shared by copy approach. For example, consider application A has artifact A which defines “customer” using a first target namespace, and application B has artifact B which defines “customer” with a different field, but using the same target namespace. For the administrative application that manages both applications A and B, copying artifacts A and B to the administrative application will cause confusion as to which “customer” to use when an instance of “customer” needs to be created.
Another well known approach is using a shared library model. For example, a shared library can be created and common java classes and artifacts can be copied to this library. This shared library can be added to an application's classpath so that the application has access to those artifacts and java classes. This approach is an improvement over the shared by copy solution. However, it still has the same drawbacks related to implementing dynamicity and data isolation as discussed above. For example, in the case of the dynamicity issue, when new artifacts are defined or created in new applications, the shared library needs to be re-deployed. In the case of data isolation, since multiple applications can see/load everything in their shared library, the issue still exists in this approach. If artifact A and artifact B define the same target namespace and type (such as “customer”), placing artifacts A and B directly into the same shared library will cause a conflict to arise. Another major drawback of this approach is the lack of remote loading. Since a shared library is local to a server or cluster, a shared library could not be used by servers on different clusters, let alone servers on different cells.
A variation of the shared library approach is using a database to store artifacts. The database in this approach is sometimes called an artifact registry. Although this approach solves the remote access/loading issue—any server/application has access to the database or artifact registry could use artifacts, this approach still does not resolve the dynamicity issue. It does not define how an application behaves when it can access conflict artifacts. Second, this approach requires database access. In Java 2 Platform Enterprise Edition (J2EE) and Java 2 Platform Standard Edition (J2SE), integrating an application with a central database is not an easy task, as it requires extensive Java Database Connectivity (JDBC) or J2EE entity bean design and programming.
Another solution has been to pass artifacts, which can include meta-data, along with instance data. This way, when a client receives instance data, it can use the attached artifact to interpret the instance data. One example of this is a scenario supported by Microsoft .Net. In this scenario, a Web Service Definition Language (“WSDL”) response generated by .Net contains a response, e.g., an instance data, along with meta-data. For example, the meta-data may be in Extensible Markup Language (“XML”), or more specifically an XML Schema Definition (“XSD”) schema. .Net expects the service caller interprets response using the attached XSD schema. The biggest problem of this approach is performance. Meta-data only needs once, after it is loaded in memory, the consequent creating instance data shall be supported. By always passing schema with instance data, the same meta-data will need to be loaded again and again for handling subsequent instance data. The second issue of this solution is that it is artifact types specific and protocol specific. The .Net approach only provides a solution for XSD schema passed using web services.